-
Notifications
You must be signed in to change notification settings - Fork 7
feat: Add streams package
#16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/typescript@5.5.4 |
46600ea to
c2a46ae
Compare
641c30f to
031a8b8
Compare
In the course of implementing #11, I made various changes to the monorepo that I deemed either necessary or simply beneficial. Here these changes are extracted from #11, which has been separated into this PR and #16. Contains the following changes: - Upgrade `ts-bridge` and migrate all packages to ESM - In the course of implementing #11, I ran into a [TypeScript project references](https://www.typescriptlang.org/docs/handbook/project-references.html)-related error, because [`ts-bridge`](https://ts-bridge.dev/) originally did not support this feature. However, [`ts-bridge` recently added support for project references](https://github.com/ts-bridge/ts-bridge/releases/tag/v7.0.0), and updating fixed the problem. - This, however, necessitated migrating all monorepo packages to be ESM-first (`"type": "module"`), and setting TypeScript's `moduleResolution` algorithm to `Node16`. So, now the entire monorepo is ESM-first, but any libraries we publish will still be importable in CommonJS, due to `ts-bridge`. - As part of this change, `.js` files were renamed to `.cjs`, and `.mjs` files to `.js`. The same goes for their `.ts` equivalents. - A notable exception includes the published files in `@ocap/shims`, which retain their `.mjs` extensions as a redundancy measure. - Fix intra-repo path resolution in tests - In the `/snaps` and `/core` monorepos, Jest's `moduleNameMapper` option is manually configured to match the `paths` property in `tsconfig.json` to ensure that tests use source code as opposed to build outputs. - In `vite`, we accomplish the same by dropping in the plugin `vite-tsconfig-paths`, with no additional configuration whatsoever. - Add internal `test-utils` package - Rather than keeping a folder of test utilities at the monorepo root, I decided to just create an internal package for this purpose. - Set the version of all intra-monorepo dependencies to `workspace:^` - This takes a queue from the Snaps monorepo. In this way, we will never accidentally pull a workspace package from npm. - Note that this required stealing some of the Snaps monorepo's constraints for our `constraints.pro`. However, don't spend too much time on that file, because it will be replaced soon: #17 - Externalize `endoify.mjs` in `extension` HTML files - Introduces our own tiny `vite` plugin, `endoifyHtmlFilesPlugin`, that inserts the `endoify.mjs` in the correct place just before HTML files are built. `vite`'s aggressive optimization and module resolution logic otherwise prevents us from doing this. - Add `clean` script to all packages - After experiencing some issues with cached builds, I decided to make sure every package has a `clean` script.
031a8b8 to
450f404
Compare
grypez
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed the newly added streams package but not the edits to the extension package. Overall, the message-channel looks like it well handles the issue of getting messages to the iframes.
The resolve-only stream implementations give me pause, but I can imagine the errors being handled at a higher level of abstraction as you indicate. I would only ask if the inability of the stream to detect its internal failure relieves it of the responsibility to support async throw (see the endo makeStream implementation for comparison). If indeed it does, then I recommend removing the reject part of the promise from the MessagePortReader implementation altogether.
This comment was marked as resolved.
This comment was marked as resolved.
bf3a868 to
14737b9
Compare
14737b9 to
dbde224
Compare
The streams originally did not have any error handling capabilities, since the underlying MessagePort was assumed to be completely reliable. This was a bad asssumption, because `MessagePort.postMessage()` does in fact throw DOMException errors under various conditions. These conditions are not necessarily plausible, but we should handle the possibility nevertheless. Therefore, the streams now include error handling, and throwing a writer will cause the reader on the opposite side to throw as well.
Bumps the default TypeScript lib for all packages from ES2020 to ES2022. This is not currently compatible with the minimum Chrome version used in the MetaMask extension (v89), but the target version (v93, ref: https://caniuse.com/?feats=mdn-javascript_builtins_array_at,mdn-javascript_builtins_regexp_hasindices,mdn-javascript_builtins_object_hasown,mdn-javascript_builtins_error_cause,mdn-javascript_operators_await_top_level,mdn-javascript_classes_private_class_fields,mdn-javascript_classes_private_class_methods,mdn-javascript_classes_static_class_fields,mdn-javascript_classes_static_initialization_blocks) is only a few versions ahead, and likely to be below the minimum by the time the Ocap Kernel makes it to production.
b34a259 to
28f3659
Compare
grypez
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Extracted from #11
Requires #15This introduces
@ocap/streams, a package that exports@endo/captp-compatible streams over the browserMessageChannel/MessagePorttransport mechanism. These streams replace the existingwindow.postMessage()transport mechanism used in the testbed extension.@endo/captpwill be introduced in a subsequent PR.Since constructing its streams requires the existence of ports,
@ocap/streamsalso establishes a simple protocol for creating aMessageChannelbetween a window and one of its iframes. To engage in this protocol, the parent callsinitializeMessageChannel()and the child callsreceiveMessagePort(). Seemessage-channel.tsfor more details.In order to make use of the Error cause feature (ref), bumps the default TypeScript
liboption fromES2020toES2022. Although this is incompatible with the current minimum Chrome version of the MetaMask extension, it will more than likely be raised by the time we need it for a production release.